File upload modifications for client side applications

ABSTRACT

Methods and systems are provided for a client computing device including a browser that renders a web page. Program code generates a mock upload event and a corresponding mock data transfer object for uploading data using the web page. The mock upload event and the corresponding mock data transfer object are propagated to an upload event listener of the web page and executed. Prior to generating the mock upload event and corresponding mock data transfer object, an embedded upload event listener may receive an upload event, read the upload event, drop the received upload event from an event handler pipeline, and call synchronously or asynchronously, code to perform logic on the received upload event for the generation of the mock upload event and a corresponding mock data transfer object.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of and claims priority to pendingU.S. patent application Ser. No. 17/708,668 entitled “FILE UPLOADMODIFICATIONS FOR CLIENT SIDE APPLICATIONS,” which was filed on Mar. 30,2022, which is a continuation of U.S. Pat. No. 11,307,911, entitled“FILE UPLOAD MODIFICATIONS FOR CLIENT SIDE APPLICATIONS,” which wasfiled on May 29, 2020, both of which are herein incorporated byreference in their entireties.

BACKGROUND

Web pages rendered in a browser interface often provide interactivecomponents, such as a drag-and-drop mechanism and/or a dialog box, thatenable a user to select files or directories to upload to a remotesystem such as a server. For example, when a user drags a file or adirectory into a drop box component in the web page, software on theclient side device receives an upload event and dispatches the event toan event handler to retrieve the file (or a list of files in adirectory), and transmit the file(s) to an identified remote system. Theupload event is propagated without modification. Furthermore, whenmultiple files are uploaded in one event, the system either transmitsall of the files or denies all of the files in the upload. Stillfurther, all files of an upload event triggered by dragging a directoryof files into a drop box are uploaded.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

Methods and systems are provided in a client computing device thatenable modification of upload events prior to the actual uploading. Inone aspect, the client computing device includes system that includes abrowser, a mock upload event generator, a dispatcher, and an eventhandler. The browser is configured to render a web page. The mock uploadevent generator includes program code configured to generate a mockupload event and a corresponding mock data transfer object for uploadingdata using the web page. The program code is configured to execute inthe client computing device. The dispatcher is configured to propagatethe mock upload event and corresponding mock data transfer object to anupload event listener of the web page. The event handler is configuredto execute the mock upload event.

In some embodiments, the client computing device includes an embeddedupload event listener. Prior to the mock upload event generatorgenerating the mock upload event and mock data transfer object, theembedded upload event listener is configured to: intercept a receivedupload event, read the received upload event, drop the received uploadevent from an upload event handler pipeline, and call code to performlogic on the received upload event.

Further features and advantages of embodiments, as well as the structureand operation of various embodiments, are described in detail below withreference to the accompanying drawings. It is noted that the methods andsystems are not limited to the specific embodiments described herein.Such embodiments are presented herein for illustrative purposes only.Additional embodiments will be apparent to persons skilled in therelevant art(s) based on the teachings contained herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate embodiments of the present applicationand, together with the description, further serve to explain theprinciples of the embodiments and to enable a person skilled in thepertinent art to make and use the embodiments.

FIG. 1 is a block diagram of a system that generates a mock upload eventin a web page for handling files being uploaded from a client device,according to an example embodiment.

FIG. 2 is a flowchart providing a method for generating a mock uploadevent for handling of files being uploaded from a client device,according to an example embodiment.

FIG. 3 is a block diagram of a system for intercepting a received uploadevent by an embedded upload event listener, and generating a mock uploadevent based on the received upload event, according to an exampleembodiment.

FIG. 4 is a flowchart providing a method for intercepting a receivedupload event by an embedded upload event listener and calling code toperform logic on the received upload event, according to an exampleembodiment.

FIG. 5 is a flowchart providing a method for sending a query about areceived upload event to a server and receiving a response including aninstruction for generating a mock upload event, according to an exampleembodiment.

FIG. 6 is a block diagram of an example processor-based computer systemthat may be used to implement various embodiments.

The features and advantages of the embodiments described herein willbecome more apparent from the detailed description set forth below whentaken in conjunction with the drawings, in which like referencecharacters identify corresponding elements throughout. In the drawings,like reference numbers generally indicate identical, functionallysimilar, and/or structurally similar elements. The drawing in which anelement first appears is indicated by the leftmost digit(s) in thecorresponding reference number.

DETAILED DESCRIPTION I. Introduction

The present specification and accompanying drawings disclose one or moreembodiments that incorporate the features of the disclosed embodiments.The scope of the embodiments is not limited only to the aspectsdisclosed herein. The disclosed embodiments merely exemplify theintended scope, and modified versions of the disclosed embodiments arealso encompassed. Embodiments are defined by the claims appended hereto.

References in the specification to “one embodiment,” “an embodiment,”“an example embodiment,” etc., indicate that the embodiment describedmay include a particular feature, structure, or characteristic, butevery embodiment may not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it is submitted that it is within the knowledge of oneskilled in the art to effect such feature, structure, or characteristicin connection with other embodiments whether or not explicitlydescribed.

Furthermore, it should be understood that spatial descriptions (e.g.,“above,” “below,” “up,” “left,” “right,” “down,” “top,” “bottom,”“vertical,” “horizontal,” etc.) used herein are for purposes ofillustration only, and that practical implementations of the structuresdescribed herein can be spatially arranged in any orientation or manner.

In the discussion, unless otherwise stated, adjectives such as“substantially” and “about” modifying a condition or relationshipcharacteristic of a feature or features of an embodiment of thedisclosure, are understood to mean that the condition or characteristicis defined to within tolerances that are acceptable for operation of theembodiment for an application for which it is intended.

Numerous exemplary embodiments are described as follows. It is notedthat any section/subsection headings provided herein are not intended tobe limiting. Embodiments are described throughout this document, and anytype of embodiment may be included under any section/subsection.Furthermore, embodiments disclosed in any section/subsection may becombined with any other embodiments described in the samesection/subsection and/or a different section/subsection in any manner.

II. Example Embodiments

As described above, today's browser based systems have limitedcapabilities when uploading files or directories of files to a remotesystem such as a server. For example, users may trigger an upload eventin a web page using an interactive component, such as a drag-and-dropbox or a dialog box, to select a file or directory for an uploadoperation. For instance, a file, multiple files, a directory, multipledirectories, or a combination thereof may be selected (i.e., one or morefiles and/or one or more directories). However, once the upload event isreceived, the event handlers are not able to modify the event. Forexample, the file content or the name of a file selected for uploadingcannot be modified. Also, when a group of files or a directory of filesis being uploaded using a drag-and-drop box or a dialog box of the webpage, the system either allows transmission all of the files, or deniesuploading all of the files. The system does not allow transmission of asubset of the files while blocking transmission of a another subset ofthe files included in the upload event. Furthermore, when dragging anddropping a directory of files for an upload operation, individual filesof the directory cannot be blocked from the upload operation based on anupload policy.

Example embodiments are described herein for controlling file anddirectory upload events (related to a web page) to a remote device sucha server, by generating a mock upload event. For example, a mock uploadevent and a corresponding mock data transfer object (e.g., an eventobject), suitable for processing by a browser, may be generated foruploading one or more files and/or one or more directories. The mockdata transfer object may include or indicate the file(s) and/ordirectory(s) designated to be uploaded and corresponding metadata. Thebrowser dispatches the mock upload event and the corresponding mock datatransfer object to propagate through a path of the document object model(DOM) tree to reach a registered mock upload event listener in the DOMtree. The mock upload event and mock data transfer object may then bepropagated through one or more event handlers (e.g., a chain of eventhandlers) to process the one or more files and/or one or moredirectories, and perform the upload operation according to the mockupload event and mock data transfer object. In some embodiments, a webpage element (e.g., a button, drag-and-drop box, input dialog box, etc.)may be rendered in a web page to receive user input to trigger executionof the mock upload event. In other embodiments, the mock upload eventmay be triggered by non-user incidences, for example, a timer output,the DOM reaching a ready state, or other state changes of elements inthe DOM tree, or may be triggered in other ways.

In some embodiments, a user activated interactive element that triggersgeneration of the mock event for upload operations may be an existinginput element in a web page for selecting files or directories forupload, for example, a dialog box or drop box for a drag-and-dropoperation (e.g., to upload file(s) and/or directory(s) to a server).When the existing upload input element is activated by the user, anupload event is received. A mock upload event listener may be embeddedin an element of the DOM tree above (prior to) any other DOM elementcomprising an event listener registered to capture the received uploadevent (e.g., the event triggered by drag-and-drop or dialog box input).The embedded mock upload event listener may capture, read, and/oranalyze the received upload event, and may drop the received uploadevent from the event processing flow of the DOM. The embedded mockupload event listener may call (synchronously or asynchronously) code toperform logic relative to the received upload event. For example, thecalled code may generate a mock upload event and mock data transferobject suitable for processing by the browser (e.g., based on thereceived upload event) to replace the received upload event. Asdescribed above, the mock data transfer object may include file(s)and/or directory(s) designated in the received upload event (e.g.,designated based on a drag-and-drop gesture or selection in a dialogbox). The embedded mock upload event listener may send the mock eventwith the mock data transfer object (e.g., as an argument) to an eventhandler and it may be propagated through one or more event handlers toprocess the one or more files and/or one or more directories, andperform the upload operation according to the mock upload event and mockdata transfer object.

In some embodiments, the mock upload event may be generated based on theoriginal received (or existing) upload event. For example, the mockupload event may include additional, fewer, or different processingsteps than the received upload event. In some embodiments, the mockupload event may add steps for modifying content of one or more files(e.g., encrypting files) and/or renaming one or more files before anupload operation. In some embodiments, the mock upload event mayindicate that upload of a portion or subset of the files or directoriesindicated in the mock data transfer object may be blocked while uploadof other files indicted in the data transfer object may be allowed.Furthermore, individual files of a directory selected by a user in adrag-and-drop gesture denial for an upload operation may be allowed orblocked based on inspection of an upload policy. The upload policy maybe stored local to the client computing device or stored on a remotedevice such as a proxy server or a web server.

In some embodiments, the embedded mock upload event listener transmits aquery to a proxy server. The query includes a request regarding thedesignated file(s) and/or directory(s). The proxy server returnsinstructions in a response to the embedded mock event listener forprocessing the file(s) and/or directory(s) prior to uploading them to aservice provider server, or for denying upload of one or more of thefiles and/or directories. The proxy service may determine theinstructions based on file upload policies as applied to the uploadrequest. For example, the upload policies may indicate criteria fortaking certain actions or indicate how to treat certain types of filesor directories (e.g., modify file content, encrypt file content, renamea file, deny transmission of certain types of files, etc.). The mockevent generator generates the mock upload event and corresponding mockdata transfer object based on the returned instructions from the proxyserver.

The mock upload event generator described herein may take various forms,for example, as a browser extension written in a scripting language code(e.g., JavaScript® developed by Mozilla Foundation of Mountain View,California), scripting language code that alters an existing event thatis received via a web page element, new scripting language code,scripting language code injected as a hook library in the web page, orother scripting language code.

Embodiments for generating a mock upload event in a web page may beimplemented in various ways. For instance, FIG. 1 is a block diagram ofa system 100 that generates a mock upload event in a web page forhandling files being uploaded from a client device, according to anexample embodiment. As shown in FIG. 1 , system 100 includes a clientcomputing device 102 and a service provider server 120 that arecommunicatively coupled by a network 130. Client computing device 102includes a browser 104, which renders a web page 106. Web page 106includes a mock upload event generator 108, a mock upload event 110, amock data transfer object 112, a dispatcher 114, an upload eventlistener 116, and an event handler 118.

Client computing device 102 may be any suitable computing device, suchas a mobile computing device (e.g., a Microsoft® Surface® device, apersonal digital assistant (PDA), a laptop computer, a notebookcomputer, a tablet computer such as an Apple iPad™, a netbook, etc.), amobile phone (e.g., a cell phone, a smart phone such as an Apple iPhone,a phone implementing the Google® Android™ operating system, a MicrosoftWindows® phone, etc.), a wearable computing device (e.g., a head-mounteddevice including smart glasses such as Google® Glass™, Oculus Rift® byOculus VR, LLC, etc.), a stationary computing device such as a desktopcomputer or PC (personal computer), a gaming console/system (e.g.,Microsoft Xbox®, Sony PlayStation®, Nintendo Wii® or Switch®, etc.), anappliance, a set top box, etc.

Service provider server 120 is implemented in one or more computingdevices, such as a desktop computer, a server, a mobile device, etc.Service provider server 120 is configured to respond to requestsreceived via network 130 from client computing device 102. Serviceprovider server 120 may be a web server comprising one or more websitesand may process incoming network requests received from client computingdevice 102 via network 130 using Hypertext Transfer Protocol (HTTP) andother related protocols. Service provider server 120 may be configuredto store, process and deliver web pages and content to client computingdevice 102. For example, web pages delivered to client computing device102 may include hypertext markup language (HTML) documents, which maycomprise images, hyperlinks, files, style sheets, scripts, graphics,text content, etc. Network 130 may be or include any type ofcommunication network, including a local area network (LAN), a wide areanetwork (WAN), a personal area network (PAN), or a combination ofcommunication networks, such as the Internet.

Client computing device 102 is configured to communicate with serviceprovider server 120 via network 130. Client computing device 102 may beconfigured to transmit a request to service provider server 120 toaccess a service provided thereby. For example, web browser 104 may be aclient application, running in client computing device 102, which isconfigured to connect to a web server of service provider server 120 andretrieve web pages such as web page 106 for rendering at clientcomputing device 102. In an embodiment, browser 104 is configured toconstruct a DOM tree based on web page 106, render content of web page106, and display web page 106 in display regions of a user interface(e.g., in a tab of browser 104) of client computing device 102.

In some embodiments, web page 106 is accessed from service providerserver 120 when web browser 104 receives a uniform resource locator(URL) address as user input via an address bar (not shown) of webbrowser 104. Web page 106 is a document that may be written in HTML(hypertext markup language) or other suitable language, and may includeor reference code for execution written in a scripting language such asJavaScript® for implementing dynamic behavior. Web page 106 may berendered in web browser 104 to include interactive elements (e.g., adrag-and-drop box, a dialog box, a button, etc.) for receiving userinput. For example, the interactive elements may be used to initiate afile or directory upload operation in order to upload one or more filesand/or one or more directories to service provider 120 server.

Note that although the JavaScript® scripting language and JavaScript®scripts are frequently discussed herein with respect to embodiments,they are discussed for illustrative purposes, and further types ofscripting languages are applicable in embodiments.

Mock upload event generator 108 may include scripting language code(e.g., JavaScript®) that is configured to generate mock upload event 110and mock data transfer object 112 for processing and uploading file(s)and/or directory(s) to service provider server 120. Mock upload event110 may be a scripting language event object (e.g., a JavaScript® event)that may be created by calling a constructor in JavaScript®, whichbuilds the mock upload event 110. Mock data transfer object 112 may begenerated separately and may be included within mock upload event 110.Mock data transfer object 112 is a valid data structure for browser 104.The structure of mock data transfer object 112 mocks or mimics thestructure of a data transfer object that would otherwise be nativelycreated by browser 104. In other words, one of the properties in themock upload event 110 is the mock data transfer object 112 that has astructure that mocks the structure of an object created by calling anexisting JavaScript® constructor. Mock data transfer object 112 holdsthe data that is selected for uploading to service provider server 120.Mock upload event 110 is configured to cause a mocked or alteredexecution flow to proceed for file or directory processing and/or uploadactions. Mock upload event 110 may cause analysis and/or processing offiles or directories prior to transmitting the file(s) and/ordirectory(s) to service provider server 120. Mock data transfer object112 may be utilized for the processing and/or upload operation. Forexample, mock data transfer object 112 may include metadata such as filename(s) or file size(s), or content of the file(s). In some embodiments,metadata of mock data transfer object 112 may also include filelocations in a directory and/or subdirectories.

Dispatcher 114 may include code configured to dispatch mock upload event110, with mock data transfer object 112 included as an argument, to anexecution flow of web page 106 to perform processing and an uploadoperation on the files designated (or included) in mock data transferobject 112, according to mock upload event 110. For example, uploadevent listener 116 may receive mock upload event 110 and mock datatransfer object 112 from dispatcher 114 and forward them to eventhandler 118 to propagate the execution flow based on mock upload event110 and mock data transfer object 112. In some embodiments, eventhandler 118 may include a plurality of event handlers, (e.g., a chain ofevent handlers through which mock upload event 110 and/or mock datatransfer object 112 are propagated).

Mock upload event generator 108 may be triggered to execute in variousways. For example, a button may be rendered in web page 106 that isconfigured to receive user input (e.g., a click), which triggers mockupload event generator 108 to generate mock upload event 110 and mockdata transfer object 112. In another example, a timer may be configuredin web page 106 or browser 104 to trigger mock upload event generator108 to generate mock upload event 110 and a mock data transfer object112 on a periodic basis, or at one or more specified times. In anotherexample, mock upload event generator 108 may be triggered to generatemock upload event 110 and mock data transfer object 112 when page 106 isfully loaded into browser 104, or based on progress of an asynchronoustask.

In some embodiments, upload event listener 116 and/or event handler 118may be registered in the DOM tree of web page 106 and may be defined forperforming one or more operations on one or more files and/or one ormore directories before transmission of the same to service providerserver 120. For example, event handler 118 may be configured to rename afile(s) before uploading the file(s) (e.g., renaming a file to include auser name or a date in the file name, etc.). In another example, eventhandler 118 may be configured to modify the content of one or more filesprior to an upload operation (e.g., encrypt a file or redact portions ofa file(s), etc.). In another example, event handler 118 is configured toanalyze mock upload event 110 and mock data transfer object 112 anddetermine, for each file or directory designated, whether an uploadoperation should be allowed or blocked. For example, prior to uploadinga directory of files, event handler 118 may be configured to analyzeeach file of the directory relative to a defined upload criteria orpolicy, and may upload only the files from the directory that meet thecriteria or satisfy the policy. Alternatively or in addition, eventhandler 118 may be configured to modify one or more of the files of thedirectory to meet the criteria or policy prior to uploading thedirectory or one or more files from the directory. Moreover, eventhandler 118 may be configured to change a list of files in a directoryor create a file system for uploading to service provider server 120.

In one embodiments, event handler 118 is configured to create a file orfiles to be uploaded to service provider server 120. For example, a fileupload button element may be added to web page 106 as a browserextension (e.g., using script code). Unlike with existing file uploaddrag-and-drop input elements or file upload dialog box input elements,which may allow a user to choose one or more files and/or one or moredirectories for uploading, user input received at the browser extensionfile upload button (e.g., a click) may trigger mock upload eventgenerator 108 to generate a mock upload event 110 and mock data transferobject 112. Mock upload event 110 may be captured by event listener 116and propagated through event handler 118. Event listener 116 may beconfigured to create a new file, fill the file with some content, andupload the new file to service provider server 120. This example usecase may enable a developer to test a web site upload process bygenerating a new file and uploading it to service provider server 120.

Mock upload event generator 108 may be configured in various ways. Forexample, mock upload event generator 108 may be a browser extensionincluding code written in a scripting language (e.g., JavaScript®). Inanother example, mock upload event generator 108 may comprise a hooklibrary that includes hook software configured to intercept a receivedupload event that is passed to the DOM, and generate a mock upload event110 and a mock data transfer object 112 to propagate in a “mock”execution flow (e.g., for modifying a file or modifying the uploadoperation), which is different from the normal execution flow for thereceived upload event. The “mock” execution flow may include processingby event handler 118.

In embodiments, system 100 may operate in various ways to perform itsfunctions. For example, FIG. 2 is a flowchart 200 providing a method forgenerating mock upload event 110 from web page 106, for handling filesto be uploaded from client device 102, according to an exampleembodiment. In one embodiment, flowchart 200 may be performed by clientcomputing device 102, and in particular, by browser 104. For thepurposes of illustration, flowchart 200 of FIG. 2 is described withreference to FIG. 1 .

Flowchart 200 of FIG. 2 begins with step 202. In step 202, a web page isrendered in a browser of the client computing device. For example,browser 104 may receive a URL, based on input by a user, that addressesweb page 106 at service provider server 120. Browser 104 may transmit arequest for web page 106 to service provider server 1020, and inresponse, receive web page 106 from service provider server 120. Browser104 then renders web page 106, retrieving objects indicated in web page106 (e.g., images, videos, etc.) as needed for the rendering. In someembodiments, web page 106 may include interactive elements for receivinguser input (e.g., a drag-and-drop box, a dialog box, a browser extensionbutton for mock upload events, etc.). The interactive elements may beused to initiate file and/or directory upload operations to process andupload one or more files and/or one or more directories to serviceprovider 120 server. Browser 104 may construct a DOM for web page 106and register upload event listener 116 and event handler 118 in one moreelements of the DOM.

In step 204, program code configured to execute in the client computingdevice generates a mock upload event and a corresponding data transferobject for uploading data using the web page. For example, mock uploadevent generator 108 may execute in client computing device 102 togenerate mock upload event 110 and mock data transfer object 112 forprocessing and/or uploading one or more files and/or one or moredirectories from client computing device 102 to service provider server120 over network 130. Execution of mock upload event generator 108 maybe triggered in various ways, for example, by user input (e.g., a clickevent) in an element rendered in web page 106, or by non-userincidences, for example, a timer output, the DOM reaching a ready state,or other state changes of elements in the DOM tree. Mock data transferobject 112 may include metadata such as file name(s), file size(s), orcontent of the file(s). In some embodiments, mock data transfer object112 may also include file locations in a directory and/orsubdirectories. In some embodiments, mock upload event generator 108 maycreate a new file to upload, fill the new file with content, and includethe new file (or designate the new file) in mock data transfer object112. Alternatively or in addition, mock upload event generator 108 maycreate a directory of files to upload, and include it (or designate it)in mock data transfer object 112.

In step 206, the mock upload event and the corresponding data transferobject are propagated to an upload event listener of the web page. Forexample, dispatcher 114 may dispatch mock upload event 110 with mockdata transfer object 112, included as an argument, to an execution flowof the DOM of web page 106. For example, upload event listener 116 mayreceive mock upload event 110 and mock data transfer object 112 fromdispatcher 114 and forward them to event handler 118 to propagate theexecution flow based on mock upload event 110 and mock data transferobject 112. In some embodiments, event handler 118 may include aplurality of event handlers, (e.g., a chain of event handlers throughwhich mock upload event 110 and/or mock data transfer object 112 arepropagated).

In step 208, the mock upload event is executed. For example, eventhandler 118 may process or create one or more files and/or one or moredirectories designated in mock data transfer object 112 and upload oneor more files and/or one or more directories to service provider server120 via network 130. As described above, in one example, event handler118 may rename one or more files before uploading the file(s) (e.g.,rename a file to include a user name or a date in the file name, etc.).In another example, event handler 118 may modify the content of one ormore files prior to an upload operation (e.g., encrypt a file or redactportions of a file, etc.). In another example, event handler 118 mayanalyze mock upload event 110 and mock data transfer object 112, anddetermine for each file designated, whether an upload operation shouldbe allowed or denied. For example, prior to uploading a directory offiles, event handler 118 may analyze each file of the directory relativeto a defined upload criteria or policy, and upload only the files fromthe directory that meet the criteria or satisfy the policy.Alternatively or in addition, event handler 118 may modify one or moreof the designated files to meet the criteria or policy prior touploading one or more files from the directory. Moreover, event handler118 may change a list of files in a directory or create a file systemfor uploading to service provider server 120. In one embodiment, eventhandler 118 is configured to create a file or files to be uploaded toservice provider server 120. For example, based on a user input triggervia an element in web page 106, or based on a non-user incidence triggerin web page 106 or browser 104 (e.g., timer output, DOM state, etc.),mock upload event generator 108 may generate mock upload event 110 andmock data transfer object 112. Mock upload event 110 and mock datatransfer object 112 may be captured by event listener 116 and propagatedthrough event handler 118. Event handler 118 may create a new file, fillthe file with content, and upload the new file to service providerserver 120.

Embodiments for generating a mock upload event in a web page may beimplemented in various ways. For instance, FIG. 3 is a block diagram ofa system 300 for intercepting a received upload event by an embeddedupload event listener, and generating a mock upload event based on thereceived upload event, according to an example embodiment. As shown inFIG. 3 , system 300 includes elements of system 100 and additionalelements. System 300 includes client computing device 102, serviceprovider 120, and a proxy server 350, which are all communicativelycoupled by network 130. Client computing device 102 includes browser104, which loaded and renders web page 106. Web page 106 includes mockupload event generator 108, mock upload event 110, mock data transferobject 112, dispatcher 114, upload event listener 116, event handler118, an embedded upload event listener 352, event modifying code 354,and an input element 356. Proxy server 350 includes a mocking eventinstruction generator 362. These features of system 300 are furtherdescribed as follows.

In some embodiments, mock upload event generator 108 may generate mockupload event 110 and mock data transfer object 112 by modifying actualfile upload events that are triggered based on dragging and dropping, orchoosing files from a dialog box in web page 106. An issue that ariseswith modifying file uploads is that different web services havedifferent protocols between the client side and the server side (e.g.,form-multipart, different AJAX methods, JSON post). However, webbrowsers tend to implement the same API for receiving files from theclient itself regardless of the client-server protocol implementation.Example APIs include: (1) dragging and dropping files and/or directories(e.g., folders) into the browser; and (2) selecting files and/ordirectories from <input type=“file” /> (e.g., choosing files from adialog box). By filtering these APIs at the first (i.e., topmost) DOMelement on the capture phase, all file upload attempts can be modifiedor selectively allowed or blocked (including selectively allowing orblocking individual files in a directory based on a policy), whilemaking sure that no file content is being read by the browser withoutapproval.

Embedded upload event listener 352 is configured to intercept a receivedupload event that is triggered when a user selects files and/ordirectories for an upload operation by dragging and dropping filesand/or directories, or choosing files and/or directories from a dialogbox of input element 356 in web page 106 (as described above). Forexample, in instances where web page 106 receives user input to initiatea file upload action via a drag-and-drop or dialog box input of element356, a JavaScript® event is created. JavaScript® event propagation inthe DOM includes three phases: (1) capture (down), (2) target and (3)bubbling (up). Embedded event listener 352 may be registered during DOMinitialization high on the DOM tree on the capture phase (e.g., on thewindow or topmost object of the DOM), such that code of embedded eventlistener 352 is the first code executed in response to the user'sattempt to upload the file utilizing the drag-and-drop or dialog boxfile selection of input element 356. Thereby, embedded event listener352 is configured to intercept the original JavaScript® event.

By intercepting the original JavaScript® event that was triggered by theuser's upload request based on drag-and-drop or dialog box input,embedded upload event listener 352 may preempt normal pipelineprocessing for the original JavaScript® event and provide an alternateflow for file or directory upload control. For example, embedded uploadevent listener 352 may read the original received upload event destinedfor the normal upload event handler pipeline, and call, synchronously orasynchronously, event modifying code 354 of mock event generator 108.Event modifying code 354 is configured to perform logic on the originalreceived upload event to generate mock upload event 110. For example,event modifying code 354 may modify or replace the original JavaScript®event to generate mock upload event 110 and mock data transfer object112, which may be propagated in a mock or altered execution flow throughevent handler 118. In this regard, event modifying code 354 of mockupload event generator 108 may be script code injected as a hook libraryin web page 106.

Mock upload event 110 may trigger additional, fewer, or differentprocessing steps than the received original upload JavaScript® event.For example, mock upload event 110 may cause added steps for modifyingcontent of one or more files (e.g., encrypting files) and/or renamingone or more files. In some embodiments, mock upload event 110 may causeupload of a subset of the files or directories indicated in mock datatransfer object 112 to be blocked while other files may be allowed toupload. Furthermore, the denial or allowance of an upload operation forone or more files, one or more files of a directory, and/or one or moredirectories may be determined based on inspection of an upload policythat may be stored local to client computing device 102 or on a remotedevice such as proxy server 350 or service provider server 120.

As described above, mock upload event generator 108 may take variousforms. For example mock upload event generator 108 may be or include abrowser extension that may be written in a scripting language (e.g.,JavaScript®) such as script code 364. In another example, mock uploadevent generator 108 may include scripting language code that alters anexisting event (e.g., an event triggered by drag-and-drop or dialog boxinput), such as event modifying code 354. In another example, mockupload event generator 108 may include new scripting language codeassociated with a non-user incident trigger or user input at a new inputelement of web page 106, such as an upload button. In another example,mock upload event generator 108 may include scripting language code thatis injected as a hook library in web page 106.

In general, in networked computer systems, proxy services are sometimesused to monitor internet traffic and enforce policy restrictions on useractivities. However, when a user of a client device uses a client-sideapplication that executes on the client (e.g., a browser application orword processing application), the proxy service may be unable to monitorthe activities undertaken by the user using the client-side application.For example, when a user uploads a document from client computing device102, proxy server 350 may not detect the user action to be able to applypolicy rules, such as file or directory upload policies defined by anadministrator of a tenant domain. As a result, the user may be able toperform actions that the administrator sought to prevent in defining thepolicy rules (e.g., uploading unencrypted files or uploading certainrestricted files).

System 300 may operate in various ways to perform its functions. Forexample, FIG. 4 is a flowchart 400 providing a method for intercepting areceived upload event by an embedded upload event listener and callingcode to perform logic on the received upload event, according to anexample embodiment. In one embodiment, flowchart 400 may be performed byclient computing device 102. For the purposes of illustration, flowchart400 of FIG. 4 is described as follows with reference to FIG. 3 .

Flowchart 400 begins with step 402. In step 402, an embedded uploadevent listener intercepts a received upload event. For example, anoriginal upload JavaScript® event may be triggered by input receivedwhen a user selects one or more files and/or one or more directories forupload using a drag-and-drop box or dialog box of input element 356.Dispatcher 114 may dispatch the original upload JavaScript® event to theDOM. Embedded upload event listener 352 may be registered above theevent listener that normally captures the original upload JavaScript®event such that code of embedded event listener 352 is first to capturethe original JavaScript® event. In one example, embedded event listener352 may be registered during DOM initialization on the window (e.g., thetopmost object) of the DOM on the capture phase, such that code ofembedded event listener 352 is the first code that runs when the userattempts the file upload utilizing file selection via the drag-and-dropbox or dialog box of input element 356, thereby intercepting theoriginal upload JavaScript® event.

In step 404, the received upload event is read. For example, embeddedupload event listener 352 may read and/or analyze the original uploadJavaScript® event. In an embodiment, embedded upload event listener 352determines the original JavaScript® event is an event type that is to bediscarded in lieu of a replacement, or to be modified. For instance, theevent type may relate to a particular user interface element thattriggers the event, a particular in page event type, or other type ofevent that is desired to be discarded or modified (e.g., in a list ofevent types for discard or modification).

In step 406, the received upload event is dropped from an upload eventhandler pipeline. For example, embedded event listener 352 may drop theoriginal upload JavaScript® event from the normal execution flow ofevent handlers that are registered in the DOM for handling upload eventstriggered by file selection input received for an upload operation, fromthe drag-and-drop box or dialog box of input element 356.

In step 408, the embedded event listener calls, synchronously orasynchronously, code to perform logic on the received upload event. Forexample, embedded event listener 352 may call event modifying code 354of mock upload event generator 108 to generate a mock upload event 110and corresponding mock data transfer object 112. As described above,event modifying code 354 may modify or replace the original uploadJavaScript® event with mock upload event 110, which may triggeradditional, fewer, or different processing steps than the receivedoriginal upload JavaScript® event. For example, mock upload event 110may include added steps for modifying content and/or renaming one ormore files, or for allowing or blocking a subset of the files ordirectories indicated in mock data transfer object 112. Furthermore, theupload of one or more files of a directory may be individually allowedor blocked based on inspection of an upload policy that may be storedlocal to the client computing device or on a remote device such as proxyserver 350 or service provider server 120.

Referring again to FIG. 3 , in some embodiments, system 300 includesproxy server 350. Proxy server 350 may be communicatively coupled toservice provider server 120 and client computing device 102 via network130. Service provider server 102 may support services and/or contentthat can be accessed by client computing device 102 through proxy server350 via network 130. When client computing device 102 attempts to accesscontent and/or services on service provider server 120 (e.g., uploadingone or more files and/or one or more directories to service providersever 120), the access may be monitored, controlled, and/or routedthrough proxy server 350.

Proxy server 350 may include mocking event instruction generator 362that includes code for applying rules and/or policies to requests fromclient computing device 102 for uploading one or more files and/or oneor more directories to service provider server 120.

In some embodiments, prior to generating mock upload event 110, mockupload event generator 108 is configured to send query 358 to proxyserver 350, via network 130. Query 358 may include a request regardingthe upload of one or more files and/or one or more directories toservice provider server 120. Query 358 may identify the one or morefiles and/or one or more directories and include metadata regarding theone or more files and/or one or more directories. Alternatively or inaddition, query 358 may include the one or more files and/or one or moredirectories indicated in the request. Mocking event instructiongenerator 362 of proxy server 350 may be configured to determine theinstructions sent in a response 360 to embedded mock event listener 352for processing the one or more files and/or one or more directories(e.g., modifying file content or renaming files), prior to an uploadoperation. Alternatively or in addition, mocking event instructiongenerator 362 may be configured to determine the instructions sent inresponse 360, which individually deny or allow upload of one or more ofthe files, one or more of the directories, and/or one or more files of adirectory of query 358. Mocking event instruction generator 362 may beconfigured to determine the instructions based on file upload policiesand or rules as applied to the upload request. For example, the uploadpolicies may indicate criteria for taking certain actions or indicatehow to treat certain files or directories (e.g., modify file content,encrypt file content, rename a file, deny transmission of certain typesof files and/or directories, etc.). Mock event generator 108 may beconfigured to receive the instructions in response 360 and generate mockupload event 110 and corresponding mock data transfer object 112 basedon the returned instructions from proxy server 350.

As described above, system 300 may perform in various ways to performits functions. For example, FIG. 5 is a flowchart 500 providing a methodfor sending a query about a received upload event to a server andreceiving a response including an instruction for generating a mockupload event, according to an example embodiment. In one embodiment,steps of flowchart 500 may be performed by client computing device 102.For the purposes of illustration, flowchart 500 of FIG. 5 is describedas follows with reference to FIG. 3 .

Flowchart 500 begins with step 502. In step 502, a query includingmetadata about the received upload event is sent to a proxy server. Forexample, mock upload generator 108 sends query 358 to proxy 350 prior togenerating mock upload event 110 and mock data transfer object 112.Query 358 may include an upload request for one or more files and/or oneor more directories specified in query 358.

In step 504, a response to the query, including instructions, isreceived from the proxy server. For example, mocking event instructiongenerator 362 may determine instructions for generating a mock uploadevent 110 and mock data transfer object 112 based on file uploadpolicies as applied to the upload request of query 358. The uploadpolicies may indicate criteria for taking certain actions or indicatehow to treat certain files or directories (e.g., modify file content,encrypt file content, rename a file, deny transmission, etc. of certaintypes of files). The instructions may be sent in response 360 andreceived by client computing device 102.

In step 506, the generating of the mock upload event and correspondingmock data transfer object is based on the instructions received from theproxy server. For example, mock event generator 108 may generate mockupload event 110 and mock data transfer object 112 based on theinstructions received from proxy server 350 in response 360.

For example, in one embodiment, embedded mock upload event listener 352sends query 358 to proxy server 350 including a request regardingdesignated one or more files and/or one or more directories. Proxyserver 350 may return instructions to embedded mock event listener 352for processing the one or more files and/or one or more directoriesprior to uploading the one or more files and/or one or more directories.Mocking event instruction generator 362 may determine the instructionsbased on file upload policies as applied to the upload request. Forexample, the upload policies may indicate criteria for taking certainactions or indicate how to treat certain files or directories (e.g.,modify file content, encrypt file content, rename a file, denytransmission of certain types of files, etc.). Mock event generator 108may generate mock upload event 110 and corresponding mock data transferobject 112 based on the returned instructions in response 360 from proxyserver 350.

III. Example Computer System Implementation

Embodiments described herein may be implemented in hardware, or hardwarecombined with software and/or firmware. For example, embodimentsdescribed herein may be implemented as computer programcode/instructions configured to be executed in one or more processorsand stored in a computer readable storage medium. Alternatively,embodiments described herein may be implemented as hardwarelogic/electrical circuitry.

As noted herein, the embodiments described, including but not limitedto, system 100 of FIG. 1 , system 300 of FIG. 3 , and system 600 of FIG.6 , along with any components and/or subcomponents thereof, as well anyoperations and portions of flowcharts/flow diagrams described hereinand/or further examples described herein, may be implemented inhardware, or hardware with any combination of software and/or firmware,including being implemented as computer program code configured to beexecuted in one or more processors and stored in a computer readablestorage medium, or being implemented as hardware logic/electricalcircuitry, such as being implemented together in a system-on-chip (SoC),a field programmable gate array (FPGA), an application specificintegrated circuit (ASIC), a trusted platform module (TPM), and/or thelike. A SoC may include an integrated circuit chip that includes one ormore of a processor (e.g., a microcontroller, microprocessor, digitalsignal processor (DSP), etc.), memory, one or more communicationinterfaces, and/or further circuits and/or embedded firmware to performits functions.

Embodiments described herein may be implemented in one or more computingdevices similar to a mobile system and/or a computing device instationary or mobile computer embodiments, including one or morefeatures of mobile systems and/or computing devices described herein, aswell as alternative features. The descriptions of computing devicesprovided herein are provided for purposes of illustration, and are notintended to be limiting. Embodiments may be implemented in further typesof computer systems, as would be known to persons skilled in therelevant art(s).

FIG. 6 is a block diagram of an example processor-based computer system600 that may be used to implement various embodiments. Client computingdevice 102, service provider server 120, network 130, and proxy server350 may each include any type of computing device, mobile or stationary,such as a desktop computer, a server, a video game console, etc. Forexample, any of client computing device 102, service provider server120, network 130, and proxy server 350 may be any type of mobilecomputing device (e.g., a Microsoft® Surface® device, a personal digitalassistant (PDA), a laptop computer, a notebook computer, a tabletcomputer such as an Apple iPad™, a netbook, etc.), a mobile phone (e.g.,a cell phone, a smart phone such as a Microsoft Windows® phone, an AppleiPhone, a phone implementing the Google® Android™ operating system,etc.), a wearable computing device (e.g., a head-mounted deviceincluding smart glasses such as Google® Glass™, Oculus Rift® by OculusVR, LLC, etc.), a stationary computing device such as a desktop computeror PC (personal computer), a gaming console/system (e.g., MicrosoftXbox®, Sony PlayStation®, Nintendo Wii® or Switch®, etc.), etc.

Client computing device 102, service provider server 120, network 130,and proxy server 350 may each be implemented in one or more computingdevices containing features similar to those of computing device 600 instationary or mobile computer embodiments and/or alternative features.The description of computing device 600 provided herein is provided forpurposes of illustration, and is not intended to be limiting.Embodiments may be implemented in further types of computer systems, aswould be known to persons skilled in the relevant art(s).

As shown in FIG. 6 , computing device 600 includes one or moreprocessors, referred to as processor circuit 602, a system memory 604,and a bus 606 that couples various system components including systemmemory 604 to processor circuit 602. Processor circuit 602 is anelectrical and/or optical circuit implemented in one or more physicalhardware electrical circuit device elements and/or integrated circuitdevices (semiconductor material chips or dies) as a central processingunit (CPU), a microcontroller, a microprocessor, and/or other physicalhardware processor circuit. Processor circuit 602 may execute programcode stored in a computer readable medium, such as program code ofoperating system 630, application programs 632, other programs 634, etc.Bus 606 represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. System memory 604 includes readonly memory (ROM) 608 and random-access memory (RAM) 610. A basicinput/output system 612 (BIOS) is stored in ROM 608.

Computing device 600 also has one or more of the following drives: ahard disk drive 614 for reading from and writing to a hard disk, amagnetic disk drive 616 for reading from or writing to a removablemagnetic disk 618, and an optical disk drive 620 for reading from orwriting to a removable optical disk 622 such as a CD ROM, DVD ROM, orother optical media. Hard disk drive 614, magnetic disk drive 616, andoptical disk drive 620 are connected to bus 606 by a hard disk driveinterface 624, a magnetic disk drive interface 626, and an optical driveinterface 628, respectively. The drives and their associatedcomputer-readable media provide nonvolatile storage of computer-readableinstructions, data structures, program modules and other data for thecomputer. Although a hard disk, a removable magnetic disk and aremovable optical disk are described, other types of hardware-basedcomputer-readable storage media can be used to store data, such as flashmemory cards, digital video disks, RAMs, ROMs, and other hardwarestorage media.

A number of program modules may be stored on the hard disk, magneticdisk, optical disk, ROM, or RAM. These programs include operating system630, one or more application programs 632, other programs 634, andprogram data 636. Application programs 632 or other programs 634 mayinclude, for example, computer program logic (e.g., computer programcode or instructions) for implementing client computing device 102,service provider server 120, network 130, proxy server 350, browser 104,web page 106, mock upload event generator 108, script code 364, mockupload event 110, mock data transfer object 112, dispatcher 114, uploadevent listener 116, event handler 118, embedded upload event listener352, event modifying code 354, input element 356, mocking eventinstruction generator 362, query 358, response 360, flowchart 200,flowchart 400, flowchart 500, and/or further embodiments describedherein. Program data 636 may include mock upload event 110, mock datatransfer object 112, query 358, response 360, and/or further embodimentsdescribed herein.

A user may enter commands and information into computing device 600through input devices such as keyboard 638 and pointing device 640.Other input devices (not shown) may include a microphone, joystick, gamepad, satellite dish, scanner, a touch screen and/or touch pad, a voicerecognition system to receive voice input, a gesture recognition systemto receive gesture input, or the like. These and other input devices areoften connected to processor circuit 602 through a serial port interface642 that is coupled to bus 606, but may be connected by otherinterfaces, such as a parallel port, game port, or a universal serialbus (USB).

A display screen 644 is also connected to bus 606 via an interface, suchas a video adapter 646. Display screen 644 may be external to, orincorporated in computing device 600. Display screen 644 may displayinformation, as well as being a user interface for receiving usercommands and/or other information (e.g., by touch, finger gestures,virtual keyboard, etc.). In addition to display screen 644, computingdevice 600 may include other peripheral output devices (not shown) suchas speakers and printers.

Computing device 600 is connected to a network 648 (e.g., the Internet)through an adaptor or network interface 650, a modem 652, or other meansfor establishing communications over the network. Modem 652, which maybe internal or external, may be connected to bus 606 via serial portinterface 642, as shown in FIG. 6 , or may be connected to bus 606 usinganother interface type, including a parallel interface.

As used herein, the terms “computer program medium,” “computer-readablemedium,” and “computer-readable storage medium” are used to refer tophysical hardware media such as the hard disk associated with hard diskdrive 614, removable magnetic disk 618, removable optical disk 622,other physical hardware media such as RAMs, ROMs, flash memory cards,digital video disks, zip disks, MEMs, nanotechnology-based storagedevices, and further types of physical/tangible hardware storage media.Such computer-readable storage media are distinguished from andnon-overlapping with communication media (do not include communicationmedia). Communication media embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave. The term “modulated data signal” means asignal that has one or more of its characteristics set or changed insuch a manner as to encode information in the signal. By way of example,and not limitation, communication media includes wireless media such asacoustic, RF, infrared and other wireless media, as well as wired media.Embodiments are also directed to such communication media that areseparate and non-overlapping with embodiments directed tocomputer-readable storage media.

As noted above, computer programs and modules (including applicationprograms 632 and other programs 634) may be stored on the hard disk,magnetic disk, optical disk, ROM, RAM, or other hardware storage medium.Such computer programs may also be received via network interface 650,serial port interface 642, or any other interface type. Such computerprograms, when executed or loaded by an application, enable computingdevice 600 to implement features of embodiments discussed herein.Accordingly, such computer programs represent controllers of computingdevice 600.

Embodiments are also directed to computer program products comprisingcomputer code or instructions stored on any computer-readable medium.Such computer program products include hard disk drives, optical diskdrives, memory device packages, portable memory sticks, memory cards,and other types of physical storage hardware.

IV. Additional Examples and Advantages

In an embodiment, a system in a client computing device comprises: abrowser configured to render a web page; a mock upload event generatorincluding program code configured to generate a mock upload event and acorresponding mock data transfer object for uploading data using the webpage. The program code is configured to execute in the client computingdevice. A dispatcher is configured to propagate the mock upload eventand the corresponding mock data transfer object to an upload eventlistener of the web page. An event handler is configured to execute themock upload event.

In an embodiment, the data includes a file, a plurality of files, adirectory, or a plurality of directories.

In an embodiment, the mock upload event performs at least one of:modifying a file, changing a file name, changing content of a file,creating a file, changing a list of files in a directory, or creating afile system.

In an embodiment, the system further comprises: an embedded upload eventlistener. Prior to the mock upload event generator generating a mockupload event and a corresponding mock data transfer object for uploadingdata using the web page, the embedded upload event listener isconfigured to: intercept a received upload event; read the receivedupload event; drop the received upload event from an upload eventhandler pipeline; and call, synchronously or asynchronously, code toperform logic on the received upload event.

In an embodiment, the program code configured to generate a mock uploadevent and a corresponding mock data transfer object for uploading datausing the web page is configured to modify the received upload event.

In an embodiment, the embedded upload event listener is configured torespond to a drag-and-drop input or a selection input in a dialogelement input of the web page.

In an embodiment, the embedded upload event listener is registered to beexecuted prior to any other event listeners of the web page.

In an embodiment, the mock upload event generator is configured to:send, to a proxy server, a query including metadata about the receivedupload event; and receive, from the proxy server, a response to thequery including instructions. The mock upload event generator includingprogram code is further configured to generate the mock upload event andthe corresponding mock data transfer object based on the instructionsreceived from the proxy server.

In an embodiment, the mock upload event generator includes at least oneof: script browser extension code; script code that alters a receivedevent; new script code; script code injected as a hook library in theweb page.

In an embodiment, the mock upload event generator is script code of ascripting language.

In an embodiment, a method in a client computing device, comprises:rendering a web page in a browser of the client computing device;generating, by program code configured to execute in the clientcomputing device, a mock upload event and a corresponding mock datatransfer object for uploading data using the web page; propagating themock upload event and the corresponding mock data transfer object to anupload event listener of the web page; and executing the mock uploadevent.

In an embodiment, the mock upload event performs at least one of:modifying a file, changing a file name, changing content of a file,creating a file, changing a list of files in a directory, or creating afile system.

In an embodiment, prior to said generating, by program code configuredto execute in the client computing device, a mock upload event and acorresponding mock data transfer object for uploading data using the webpage, the method further comprises: intercepting, by an embedded uploadevent listener, a received upload event; reading, the received uploadevent; dropping the received upload event from an upload event handlerpipeline; and calling synchronously or asynchronously, by the embeddedevent listener, code to perform logic on the received upload event forsaid generating.

In an embodiment, said embedded upload event listener is registered tobe executed prior to any other event listeners of the web page.

In an embodiment, the method further comprises: sending, to a proxyserver, a query including metadata about the received upload event; andreceiving, from the proxy server, a response to the query includinginstructions. Said generating, by program code configured to execute inthe client computing device, a mock upload event and a correspondingmock data transfer object for uploading data using the web page is basedon the instructions received from the proxy server.

In an embodiment, the mock upload event generator includes at least oneof: script browser extension code; script code that alters a receivedevent; new script code; script code injected as a hook library in theweb page.

In an embodiment, the mock upload event generator is script code of ascripting language.

In an embodiment, a computer-readable medium having program coderecorded thereon that when executed by at least one processor causes theat least one processor to perform a method, the method comprises:rendering a web page in a browser of the client computing device;generating, by program code configured to execute in the clientcomputing device, a mock upload event and a corresponding mock datatransfer object for uploading data using the web page; propagating themock upload event and the corresponding mock data transfer object to anupload event listener of the web page; and executing the mock uploadevent.

In an embodiment, prior to said generating, by program code configuredto execute in the client computing device, a mock upload event and acorresponding mock data transfer object for uploading data using the webpage, the method further comprises: intercepting, by an embedded uploadevent listener, a received upload event; reading the received uploadevent; dropping the received upload event from an upload event handlerpipeline; and calling synchronously or asynchronously, by the embeddedevent listener, code to perform logic on the received upload event forsaid generating.

In an embodiment, the method further comprises: sending, to a proxyserver, a query including metadata about the received upload event; andreceiving, from the proxy server, a response to the query includinginstructions. Said generating, by program code configured to execute inthe client computing device, a mock upload event and a correspondingmock data transfer object for uploading data using the web page is basedon the instructions received from the proxy server.

V. CONCLUSION

While various embodiments of the present application have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. It will be understood by those skilledin the relevant art(s) that various changes in form and details may bemade therein without departing from the spirit and scope of theapplication as defined in the appended claims. Accordingly, the breadthand scope of the present application should not be limited by any of theabove-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

1. (canceled)
 2. A system in a proxy server, the system comprising: aprocessor; and a memory device that stores program code to be executedby the processor, the program code comprising a mocking eventinstruction generator that: determines instructions for generating amock upload event to a service provider server from a client device, theinstructions determined in response to an upload request query receivedfrom the client device, wherein the instructions are determined based onupload policies as applied to the upload request query from the clientdevice; and transmits the instructions to the client device.
 3. Thesystem of claim 2, wherein said instructions for generating a mockupload event to a service provider server from a client device includeinstructions for generating a mock data transfer object for the mockupload event based on the upload policies as applied to the uploadrequest query from the client device.
 4. The system of claim 2, whereinthe instructions determined for generating a mock upload event to aservice provider server from a client device is based on informationabout one or more files, one or more directories, or one or more filesand one or more directories that is indicated in the upload event queryreceived from the client device.
 5. The system of claim 2, wherein theinstructions determined for generating a mock upload event to a serviceprovider server from a client device are determined based on one or morefiles, one or more directories, or one or more files, and one or moredirectories included in the upload event query received from the clientdevice.
 6. The system of claim 2, wherein the upload policies indicateat least one of criteria for taking certain actions or how to treatcertain files or directories for the generating of the mock upload eventto the service provider server from the client device.
 7. The system ofclaim 2, wherein the instructions include instructions for one or moreof modifying file content, encrypting file content, renaming a file, ordenying transmission of certain types of files or directories.
 8. Thesystem of claim 2, wherein the instructions for generating the mockupload event to the service provider server from the client deviceindicate to individually deny or allow upload of one or more of files,one or more directories, or one or more files of a directory.
 9. Thesystem of claim 2, wherein the upload request query is received at theproxy server from the client device after the client device receives auser or system generated upload event trigger and prior to the clientdevice performing an upload event in response to the trigger.
 10. Thesystem of claim 2, wherein the transmission of instructions to theclient device comprises the proxy server returning the instructions forthe generation of the mock upload event to a mock event listenerembedded in a document object model (DOM) at the client device forprocessing a file or directory prior to uploading the file or directoryto the service provider server.
 11. A method in a proxy server, themethod comprising: determining instructions that generate a mock uploadevent to a service provider server from a client device, theinstructions determined in response to an upload request query receivedfrom the client device, wherein said determining of the instructions isbased on upload policies as applied to the upload request query from theclient device; and transmitting the instructions to the client device.12. The method of claim 11, wherein the instructions that generate amock upload event to a service provider server from a client deviceinclude instructions for generating a mock data transfer object for themock upload event based on the upload policies as applied to the uploadrequest query from the client device.
 13. The method of claim 11,wherein said determining instructions for generating a mock upload eventto a service provider server from a client device is based oninformation about one or more files, one or more directories, or one ormore files and one or more directories that is indicated in the uploadevent query received from the client device.
 14. The method of claim 11,wherein said determining instructions for generating a mock upload eventto a service provider server from a client device is based on one ormore files, one or more directories, or one or more files and one ormore directories included in the upload event query received from theclient device.
 15. The method of claim 11, wherein the upload policiesindicate one or both of criteria for taking certain actions or how totreat certain files or directories for the generating of the mock uploadevent to the service provider server from the client device.
 16. Themethod of claim 11, wherein the instructions include instructions forone or more of modifying file content, encrypting file content, renaminga file, or denying transmission of certain types of files ordirectories.
 17. The method of claim 11, wherein the instructions forgenerating the mock upload event to the service provider server from theclient device indicate to individually deny or allow upload of one ormore of files, one or more directories, or one or more files of adirectory.
 18. The method of claim 11, wherein the upload request queryis received at the proxy server from the client device after the clientdevice receives a user or system generated upload event trigger andprior to the client device performing an upload event in response to thetrigger.
 19. The method of claim 11, wherein said transmitting theinstructions to the client device comprises: the proxy server returningthe instructions for the generation of the mock upload event to a mockevent listener embedded in a document object model (DOM) at the clientdevice for processing a file or directory prior to uploading the file ordirectory to the service provider server.
 20. A physical hardwarecomputer-readable medium having program code recorded thereon that whenexecuted by at least one processor causes the at least one processor toperform a method, the method comprising: determining instructions thatgenerate a mock upload event to a service provider server from a clientdevice, the instructions determined in response to an upload requestquery received from the client device, wherein said determining of theinstructions is based on upload policies as applied to the uploadrequest query from the client device; and transmitting the instructionsto the client device.
 21. The physical hardware computer-readable mediumof claim 20, wherein said instructions that generate a mock upload eventto a service provider server from a client device include instructionsfor generating a mock data transfer object for the mock upload eventbased on the upload policies as applied to the upload request query fromthe client device.